אתרים כיום חייבים להיות נגישים יום ולילה מכל מקום בעולם, על כן אפליקציות web שאינן בטוחות חושפות פתח להתקפות על בסיס הנתונים שמקושר לאתר.

Transcription

1 מבוא קיימת נטייה, אשר הולכת וגוברת, לנהל מידע ועסקים בצורה אלקטרונית בעזרת רשת האינטרנט. נטייה זו דוחפת אימוץ של שימוש בטכנולוגיות מבוססות.web קיים מגוון רחב של אפליקציות web כדוגמת: עגלת קניות, מילויי טפסים, ביצוע,login אתרים בעלי תוכן דינאמי ואפליקציות ייעודיות. אפליקציות אלו מהוות חלק בלתי נפרד מהאתרים של ימנו, הן מתווכות בין לקוחות לספקים. למעשה, אפליקציות אלו נועדו לאפשר למבקרי האתר לטעון ולשלוף תוכן דינאמי אשר כולל מידע אישי ברמות שונות של רגישות הנשמר בבסיס הנתונים..1 אתרים כיום חייבים להיות נגישים יום ולילה מכל מקום בעולם, על כן אפליקציות web שאינן בטוחות חושפות פתח להתקפות על בסיס הנתונים שמקושר לאתר. באופן כללי, נקודות התורפה של אפליקציות web חשפו בעיות שונות של אבטחה שלא היו ידועות לפני כן. תוקפים מנצלים נקודות תורפה אלו על מנת לגנוב מידע רגיש, למשל מספר כרטיס אשראי של לקוח, ולאחר מכן הם מנצלים את המידע הזה בעיקר למטרות רווח. בנוסף לפגיעה בלקוחות, התקפות על האתר פוגעות במוניטין של העסק שמאחוריו ואף לעיתים עלולות להביא לקריסתו. יתר על כן, לאחרונה נתגלה שלא רק שתוקפים מוכרים את המידע שהשיגו באתר מסוים, אלא, הם מוכרים את עצם העובדה שאתר כלשהו חשוף להתקפות להאקרים אחרים, למרגלים ואף לטרוריסטים. אבטחת אפליקציות web מתמקדת ב: הגנה על קוד האפליקציה. הגנה על ספריות קוד. הגנה על מערכות פנימיות systems(.)backend הגנה על שרתים לעומת אבטחת אפליקציות,web אבטחת רשת ( Detection Firewalls, SSL, Intrusion )Systems, Operating System Hardening, Database Hardening מתעלמת מהתוכן של תעבורת,HTTP מכאן שמדובר בסוגי אבטחה שונים ולכן לא ניתן באמצעות אבטחת רשת למנוע התקפות ברמת האפליקציה. 1

2 Network Layer Application Layer Firewall Firewall Databases Legacy Systems Web Services Directories Human Resrcs Billing הגנה במערכות מתוכנתות Your Code is Part of Your Security Perimeter Your security perimeter has huge holes at the application layer APPLICATION ATTACK Custom Developed Application Code App Server Web Server Hardened OS You can t use network layer protection (firewall, SSL, IDS, hardening) הדיאגראמה נלקחה מתוך attacks מצגת layer המתארת את application רשימת ה- stopשלowaspto Top or 10detect לשנת 2004 OWASP )מס' 2 ברשימת המקורות(. חשיבות אבטחת אפליקציות web התקפות :web.2 א. ב. ג. ד. נפוצות מאוד. קל לבצע אותן, גם ללא כלים או ידע מיוחדים. סיכוי נמוך לגילוי מבצע ההתקפה. חלק קטן מאוד ממפתחי אפליקציות web שמים דגש על נושא האבטחה. תוצאות אפשריות של התקפות :web א. ב. ג. ד. ה. שימוש או חשיפה של תוכן בסיס הנתונים. קבלת הרשאות גישה של root לשרתי.web אי יכולת לבצע אימות או בקרת כניסה של משתמשים. השבתה של האתר או שיבוש שלו. ניצול האתר לביצוע התקפות נוספות על אתרים אחרים. 2

3 10 ההתקפות המסוכנות ביותר של אפליקציית :web נתאר את 10 ההתקפות המסוכנות ביותר על אפליקציות web לשנת 2007 כפי שדורגו ע"י,)Open Web Application Security Project( OWASP קהילה בינלאומית המתמקדת בשיפור של אבטחת אפליקציות..3 הגרף הבא מתאר את ההתקפות ושכיחותן: הדיאגראמה נלקחה מתוך מסמך המתארת את רשימת ה- Top 10 של OWASP לשנת 2007.) Cross-Site Scripting (XSS) Flaws סקירה כללית התקפת XSS הינה התקפה מסוג injection בה קוד או סקריפט זדוני מושתל לתוך אתרים חוקיים ואמינים. כיום דפדפנים רבים מריצים קוד שנשלח אליהם מאתרים flash( JavaScript, ועוד(, בהתקפות XSS תוקף משתמש בעובדה זו ומנצל אפליקציית web על מנת לשלוח קוד זדוני, לרוב קוד המוסווה לסקריפט, למשתמש קצה אחר אותו הוא רוצה להתקיף. לדפדפן של המשתמש המותקף אין כל יכולת להבחין בין סקריפט חוקי לבין סקריפט זדוני שאין לבטוח בו ולכן הוא יריץ אותו. מכוון שהדפדפן של המשתמש המותקף חושב שהסקריפט נשלח ממקור)אתר( אמין הסקריפט יכול לגשת ל- session tokens,cookies וכל מידע רגיש אחר 3

4 אשר נשמר ע"י הדפדפן. יתרה מכך, סקריפטים אלו אף יכולים לשכתב את תוכן דף ה- HTML המוצג ע"י הדפדפן של המשתמש המותקף. התקפות אלו הן די נפוצות ומתאפשרות בקלות בקרב אפליקציות web אשר מקבלות קלט מהמשתמש ומייצרות ממנו פלט ללא שימוש בוולידציה או הצפנה. יש לשים לב שגם אתרים שאינם מקבלים קלט מהמשתמש כגון אתרי only" "read פגיעים להתקפות.XSS נכון ל , מתוך כל 10 אתרים פגיע להתקפות.XSS הדיאגראמה נלקחה מתוך מצגת המתארת את רשימת ה- Top 10 של WhiteHat Security לשנת 2009 )מס' 7 ברשימת המקורות( תיאור התקפות XSS מתרחשות כאשר: מידע נכנס לאפליקציית web דרך מקור לא אמין, בדרך כלל דרך בקשות web )בקשת.)HTTP מידע נכלל בתוך תוכן דינאמי ונשלח למשתמש של האפליקציה מבלי לוודא שאינו מכיל קוד זדוני..1.2 בדרך כלל הקוד הזדוני הנשלח לדפדפן של המשתמש המותקף הינו קטע של,JavaScript אך הוא גם יכול להיות מוכל בתוך דף Flash,HTML או בתוך כל קוד אחר שהדפדפן יכול להריץ. יש מגוון רחב של התקפות,XSS לרוב המרכיב המשותף להתקפות אלו הינו העברת מידע פרטי של המותקף לתוקף, לדוגמה cookies או מידע אחר על ה session של המותקף, הפניית המשתמש המותקף לתוכן web שנשלט ע"י התוקף או ביצוע מגוון של פעולות זדוניות על מחשב המשתמש במסווה האתר שדרכו מתבצעת ההתקפה. התקפות XSS נחלקות לשתי קטגוריות עיקריות:.Reflected XSS,Stored XSS ישנה התקפה שלישית הרבה פחות נפוצה שנקראת התקפת XSS מבוססת.DOM 4

5 התקפת Stored XSS בהתקפות Stored XSS )נקראת גם )Persistent XSS התוקף מנצל חולשה בשרת המותקף ומשתיל בו באופן קבוע את הקוד הזדוני, לדוגמא, בבסיס הנתונים, בפורום הודעות, ב log מבקרים, בשדה הערות וכדומה. משתמש שפונה לקבלת שירותים מהשרת מקבל את הסקריפט הזדוני ומריץ אותו. למעשה, התוקף משתיל את הקוד בשרת פעם אחת בלבד, והקוד תוקף פעמים רבות, בכל פעם שמשתמש פונה לקבל שירות מסוים מהשרת. נשים לב שאומנם יש קשר ישיר בין התוקף לשרת המותקף אך לא בהכרח יש קשר ישיר בין התוקף למשתמשים המותקפים. הדיאגראמה נלקחה מתוך מצגת המתארת את התקפות ה- XSS השונות 16 ברשימת המקורות(. )מס' התקפת Reflected XSS התקפות Reflected XSS מנצלות חולשות בשרת,web הן גורמות למשתמש בעזרת צד שלישי )לרוב באמצעות social engineering כגון הודעת מייל או שרת web אחר( ללחוץ על לינק או למלא טופס שעוצב במיוחד ע"י התוקף ובכך לשלוח לשרת הפגיע בקשת HTML בעייתית המכילה קוד זדוני, כתגובה לבקשה זו השרת יוצר דף HTML שמוחזר בחזרה למשתמש המותקף, כאשר דף זה מכיל את הקוד הזדוני שהיה בבקשה המקורית. המשתמש מריץ את הקוד הזדוני כיוון שהוא חושב שהקוד הגיע ממקור אמין. למעשה השרת "משקף" את הקוד שהוא מקבל בבקשה הבעייתית חזרה אל המשתמש ומכאן בא שם ההתקפה.Reflected XSS 5

6 הדיאגראמה נלקחה מתוך מצגת המתארת את התקפות ה- XSS השונות 16 ברשימת המקורות(. )מס' התקפת XSS מבוססת DOM XSS ה. תקפות XML ו HTML של דפי parsing זוהי קונבנציה המסייעת ב DOM מבוססת DOM )נקראת גם )Local XSS אינה משנה את דף ה HTML שהתקבל, אלא היא משנה את הסביבה של ה DOM ובאופן זה הדפדפן מריץ את הדף בצורה שונה מהמתוכנן, כאשר השרת כלל אינו מודע להתקפה הזו. הדיאגראמה נלקחה מתוך מצגת המתארת את התקפות ה- XSS השונות 16 ברשימת המקורות(. )מס' 6

7 השלכות השלכותיה של התקפת XSS הן זהות בין אם זו הייתה התקפת reflected,stored או,DOM שכן ההבדל היחידי הוא כיצד הקוד הזדוני מגיע לשרת המותקף. התקפת XSS יכולה לגרום למגוון רחב של בעיות למשתמש הקצה, החל מלהוות מטרד וכלה בסיכון חשבונו של המשתמש המותקף והפיכתו לפגיע. התקפות ה- XSS החמורות ביותר כוללות חשיפת ה- session וה- cookie של המשתמש, דבר המאפשר חטיפת הקשר hijacking( )session והשתלטות על חשבון המשתמש. התקפות מזיקות נוספות כוללות חשיפת קבצי משתמש, התקנת סוסים טרויאניים, הפניית המשתמש לאתרים אחרים או שינוי התוכן של דף HTML שמוצג למשתמש דוגמאות ב JavaScript הפונקציה "alert" גורמת להופעה של popup box עם ההודעה המתאימה. בכל הדוגמאות להלן במקום בו מופיעה הקריאה לפונקציה alert הייתה יכולה להופיע קריאה לפונקציה המכילה קוד זדוני. 1. דוגמה לשתילת סקריפט זדוני בתוך attribute של אלמנט: ניתן לבצע התקפות XSS מבלי להשתמש בתג הHTML <script></script> )לרוב משתמשים בתג זה כדי לגרום לדפדפן להריץ קוד(, אלא להשתמש בתגים אחרים אשר יבצעו בדיוק את אותו הדבר. לדוגמא: בדוגמה זו בעת טעינת דף ה HTML יורץ הסקריפט הזדוני. <body onload=alert('test1')>. ניתן גם לשתול סקריפט זדוני בעזרת attribites של אלמנטים במסמך HTML כמו: <b onmouseover=alert('wufff!')>click me!</b> בדוגמה זו בעת מעבר עם העכבר על המילים me!" "click יורץ הסקריפט הזדוני. <img src=" onerror=alert(document.cookie);> בדוגמה זו בעת ניסיון טעינת התמונה יורץ הסקריפט הזדוני )שכן המקור של התמונה לא קיים ולא תתאפשר טעינה(. 2. דוגמה לשתילת סקריפט זדוני ע"י שימוש בקידוד של :URI ניתן לקודד את המחרוזות על מנת להסתיר את הפעלת הקוד הזדוני מפני סינונים שמבצעות אפליקציות web ל. דוגמא, בעזרת UTF8 ניתן לקודד את התו a כ- X41#& וע"י שימוש בתג IMG שמציג תמונה ניתן להפעיל את הקוד הזדוני. 7

8 <IMG SRC=j&#X41vascript:alert('test2')> <IMG SRC=javascript:alert('test2')> תג זה מתורגם לתג הבא: בדוגמה זו בעת ניסיון טעינת התמונה יורץ הסקריפט הזדוני שכן המקור של התמונה הוא סקריפט. 3. דוגמה לשתילת סקריפט ע"י שימוש בקידוד של הקוד ניתן לקודד את הסקריפט הזדוני עצמו בבסיס 64 ולהשתמש בו ישירות בתג META ובכך להיפטר מהצורך בהפעלת.alert)( <META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzd DMnKTwvc2NyaXB0Pg"> 4. דוגמה לשתילת סקריפט כחלק מה : URL לינק לגיטימי יכול להיראות כך: ואילו לינק זדוני יכול להיראות כך: code')</script> התקפות נוספות ניתן למצוא בלינק הבא: דרכי התגוננות דרך ההתגוננות הטובה ביותר מפני מתקפות XSS היא ביצוע בדיקת whitelist של הקלט, כלומר מגבלים את הקלט לערכים מותרים, וכל מה שלא מותר במפורש נחשב לקלט לא חוקי. יש לשלב בדיקת whitelist עם קידוד )encoding( מתאים של המידע שנשלח למשתמש האפליקציה כפלט. בדיקת הקלט מאפשרת לאתר התקפות, ואילו קידוד הפלט מונע הרצת קוד זדוני בדפדפן של המשתמש )גם אם קוד זה הושתל בפלט אותו האפליקציה שולחת למשתמש(. כמו כן, אין לנסות להסיר תוכן אקטיבי הניתן להרצה, שכן יש סוגים רבים מאוד של תוכן, במקום זה יש להשתמש בגישה "חיובית", להגדיר בדיוק איזה סוג תוכן כן ניתן להריץ. 8

9 מניעת של התקפות XSS באפליקציה כולה דורשת ארכיטקטורה עקבית של האפליקציה כולה הכוללת: ביצוע בדיקה של הקלט- יש להשתמש במנגנונים הסטנדרטיים בכדי לבדוק את תקינות הקלט, לבדוק את האורך, הסוג, החוקיות וההיגיון העסקי של הקלט לפני שמקבלים את הקלט ומציגים או שומרים אותו. יש לקבל קלט שעובר את הבדיקות ויש לדחות כל קלט שאינו עובר את הבדיקות במקום לנסות ולתקן קלט שעלול להכיל קוד זדוני. יש לזכור כי גם הודעות שגיאה יכולות להכיל מידע לא חוקי. ביצוע -strong output encoding יש לוודא כי כל מידע שהגיע ממשתמש כלשהו עוברencoding entity לפני שהוא מוצג, כאשר הקידוד צריך להתאים לצורת הפלט,XML(.)HTML יש לקודד כל תו ותו, פרט לקבוצה מוגבלת של תווים. בנוסף, יש לקבוע את סוג character encoding עבור כל דף ודף המוצג ללקוח, ובכך להקטין את החשיפה למספר צורות של ההתקפה הגדרה ברורה של קידוד הפלט- יש להימנע ממצב בו התוקף יכול לבחור עבור המשתמש של האפליקציה את הקידוד, לכן יש להגדיר את הקידוד במפורש לדוגמה קידוד ISO עבור עברית או.UTF-8 הימנעות משימוש בבדיקות מסוג -blacklist בעת בדיקת קלט או קידוד פלט אין לבצע חיפוש והחלפה של מספר קטן של תווים )">", "<" script וכו'( בתוך דף ה- HTML שנשלח כפלט למשתמש, שכן זוהי שיטה חלשה שנעקפה בהצלחה כבר בעבר. אפילו התג "<b>" אינו בטוח בחלק מהמקרים. התקפות XSS מכילות מגוון רחב של סוגים המאפשרים לעקוף בדיקות.blacklist הישמרות מפני שגיאות сanonization יש לעשות decoding לקלט ולהתאים אותו לפורמט הפנימי בו האפליקציה משתמשת, כל זאת לפני ביצוע בדיקות תקינות הקלט, בנוסף יש לוודא כי היישום לא יקודד פעמיים. ניתן להשתמש בטעויות אלו כדי לעקוף בדיקות whitelist וזאת כיוון שהקלט המסוכן מופיע רק לאחר שעושים decoding )במידה וה- decoding נעשה אחרי שהקלט נבדק ונצא תקין( התקפות מפורסמות באוקטובר 2005 משתמש של הרשת החברתית MySpace הצליח למצוא דרך להכריח משתמשים אחרים להפוך לחברים שלו ברשת ובכך יצר את תולעת ה XSS הראשונה שמפיצה את עצמה. התולעת הפיצה את עצמה בקצב של כ 1000 משתמשים בכמה שניות, כתבה hero" " but most of all, Samy is my בפרופיל של הקורבנות וכך תוך פחות מ 24 שעות הצליח המשתמש "סמי" לאסוף יותר ממיליון חברים לפני שMySpace הורידו את האתר. התולעת ניצלה את העובדה ש MySpace לא חסמו את תג ה-"> CSS <" שנועד להגדיר את אופן התצוגה של האתר ושדפדפנים מסוימים כמו internet explorer מאפשרים קוד JavaScript בתוך תגים אלה. אילו הסקריפט של התולעת היה נכתב במטרה זדונית ולא למטרת שעשוע היה ניתן לנצל חורי אבטחה בדפדפן internet explorer וליצור בוטנט מאסיבי של MySpace שיכיל המוני מחשבים. 9

10 Injection Flaws סקירה כללית אפליקציות web משתמשות בהרבה מערכות חיצוניות כדוגמת בסיס נתונים, קריאות של מערכת ההפעלה וכו'. כאשר אפליקציות web משתמשות במערכות אלה, הן מעבירות להן כפרמטרים נתונים שהתקבלו בבקשת ה.HTTP תוקף יכול לשתול קוד זדוני בפרמטרים אלה ולגרום למערכת החיצונית לבצע קוד זדוני זה בשם אפליקציית ה.web אם כן, בעיית ה- injection קורת כאשר מידע שסופק ע"י המשתמש מועבר ל- interpreter כחלק מאיזושהי פקודה או שאילתה, והתוקף מתמרן את ה- interpreter לבצע פקודות לא רצויות שהועברו כחלק מהמידע. בעיות injection מאפשרות לתוקף לקרוא, לעדכן ואף למחוק כל מידע שנגיש לאפליקציית ה.web במקרה הגרוע ביותר בעיות אלה גורמות לסיכון אפליקציה כולה ופגיעה בה ובכל המערכות החיצוניות בהן היא משתמשת, גם אם מערכות אלה נמצאות בסביבה שמוגנת ע"י.firewalls בעיות,injection במיוחד,SQL injection מאוד נפוצות באפליקציות,web אך קיימים סוגי, HQL, LDAP, XPath, XQuery, XSLT, HTML, XML נוספים כגון injection injection של פקודות מערכת ההפעלה ועוד דוגמאות דוגמה ל :SQL injection נניח כי השאילתה היא: SELECT * FROM items WHERE owner = ' ' AND itemname = ' '; כאשר מתאר קלט שאפליקציית ה- web קיבלה מהמשתמש )ולא עשתה לו בדיקה מתאימה(. שאילתה זו מחזירה את כל השורות בטבלה items שעמודות ה,owner itemname שלהן שוות לערכים נתונים. אם בעת ההזנה המשתמש מספק את הנתונים: owner = wiley itemname = name' OR 'a'='a כעת השאילתה הופכת להיות: SELECT * FROM items WHERE owner = 'wiley' AND itemname = 'name' OR 'a'='a'; שאילתה זו מחזירה את כל השורות בטבלה items שעמודות ה itemname,owner שלהן שוות לערכים נתונים או שמתקיים 'a'='a' )וזה מתקיים תמיד(. אם כן, התוספת של 'a'='a' 10

11 גורמת לכך שהתנאי של ה- WHERE תמיד יהיה נכון, ולמעשה קיבלנו כעת שאילתה השקולה לשאילתה: SELECT * FROM items; כלומר, תוצאת השאילתה שקולה להצגה של כל הטבלה.items דרכי התגוננות יש להיזהר בעת העברת נתונים למערכת חיצונית ויש להימנע משימוש ב interpreters כאשר הדבר אפשרי. אם חייבים להשתמש ב-,interpreter ניתן להימנע מהתקפות של injection ע"י שימוש בממשקים כגון שאילתות שהן strongly typed ובעלות פרמטרים מוגדרים, או בספריות,)object relational mapping( ORM דוגמה נוספת היא PreparedStatement המשמש לגישה בטוחה לבסיס נתונים ב-.Java אומנם ממשקים אלה פותרים את בעיית ה-,injection אך עדיין מומלץ לבצע בדיקה של הקלט על מנת לאתר התקפות. בנוסף לשימוש בממשקים הבטוחים יש לבדוק גם את ערכי החזרה מהמערכות החיצוניות שמשתמשים בהן התקפות מפורסמות בפברואר 2009 חוקר מצא שאתר הבית של האנטי וירוס קספרסקי בארה"ב רגיש להתקפת SQL Injection המאפשרת לחשוף מידע אודות כל הלקוחות של האנטי וירוס. הרגישות להתקפה הייתה קיימת כבר זמן מה, החוקר דיווח על הרגישות לקספרסקי לפני שהוא פרסם אותה. בסוף תחילת 2005 תוקף ביצע התקפת SQL Injection באתר של חברת CardSystems Solutions חב, רה שעיבדה עבור חברות האשראי מידע לגבי תשלומים. התוקף חשף את פרטיהם של 40 מיליון כרטיסי אשראי, גנב את פרטיהם של 264,000 כרטיסים וגרם לחוב של מספר מיליוני דולרים ברכישות שנעשו באמצעות הכרטיסים המזויפים. אירוע זה גרם ל- CardSystems Solutions כמעט לפשוט את הרגל. Malicious File Execution סקירה כללית קוד הפגיע להתקפות Malicious File Execution ולהתקפות Remote File Inclusion (RFI) מאפשר לתוקפים להוסיף מידע או קוד זדוני, דבר העלול לגרום להתקפות הרות אסון, לדוגמה סיכון השרת כולו. התקפות מסוג Malicious File Execution משפיעות על XML,PHP ומערכות רבות נוספות אשר מאפשרות קבלת references חיצוניים כגון,URL שמות קבצים או קבצים מהמשתמשים. אפליקציות רבות פגיעות להתקפה זו, שכן רוב המפתחים בוטחים בקבצי קלט, משתמשים בהם ישירות, או משרשרים קלט שעלול להיות מסוכן לקובץ או.stream כאשר אין בדיקה מספקת של הקובץ או המידע, הדבר יכול להוביל לכך ששרת ה- web יוסיף, יעבד או יבצע קוד שרירותי העלול להיות זדוני. 11

12 התקפות אלה יכולות לאפשר לתוקף לבצע קוד מרחוק execution(,)remote code להתקין מרחוק,root kit לסכן את המערכת כולה ולפגוע בה. התקפה זו שכיחה בעיקר ב-,PHP שם, בעת שימוש ב streams או,file functions יש להקפיד ולהיזהר שקלט שהתקבל מהמשתמש אינו משפיע על שמות של קבצים דוגמאות דוגמה ב :PHP include $_REQUEST['filename ]; כאשר פקודה זו מופיעה בשרת היא מאפשרת ביצוע של סקריפטים מרוחקים שעלולים להיות זדוניים, ואף נותנת גישה לשרתי קבצים מקומיים במידה ובשרת יש PHP על מערכת הפעלה,windows וזאת בגלל שPHP תומך ב SMB )פרוטוקול המאפשר שיתוף קבצים, פורטים, מדפסות וכו'...(. ניתן להריץ סקריפטים זדוניים באופן הבא: example.com/c99.php? דרכי התגוננות על מנת למנוע ליקויים המאפשרים התקפות RFI יש לבצע תכנון מדויק וזהיר כבר בשלבים של הארכיטקטורה וה- design ויש לבצע בדיקות מקיפות בשלב ה-.testing באופן כללי, על מנת לכתוב היטב אפליקציה אין להשתמש בקלט שהתקבל מהמשתמש בעת גישה לשמות של קבצים או לכל משאב הנמצא על שרת ה.web כמו כן יש להשתמש בחוקי firewall שימנעו חיבורים מיותרים, בין אם זהו חיבור משרת ברשת הפנימית לאינטרנט, חיבור מהאינטרנט לשרת פנימי או חיבור בין שרתים פנימיים או מערכות פנימיות התקפות מפורסמות ביולי 2009 התגלו ב אפליקציית web מבוססת PHP בשם V-Webmail חולשות רבות להתקפות,RFI בהן משתמש מרוחק יכול לבצע דרך ה URL קוד PHP ופקודות מערכת הפעלה שרירותיות על המערכת המותקפת עם הרשאות של ה- web service המותקף. ההתקפה מנצלת את העובדה שכאשר מעבירים קובץ כפרמטר, אין בדיקה מספקת של הקובץ. 12

13 י- הגנה במערכות מתוכנתות Insecure Direct Object Reference סקירה כללית התקפה זו קורת כאשר מפתח חושף reference לאובייקט הקשור למימוש פנימי )קובץ, ספרייה, רשומה של בסיס הנתונים, מפתח וכו' כ( - URL או כפרמטר של טופס אותו ממלא המשתמש. אם אין מערכת פעילה של בקרת גישה, תוקף יכול לבצע מניפולציה על ה- reference החשוף ובכך לאפשר לעצמו לגשת לאובייקטים אחרים ללא אישור. בעזרת התקפה זו תוקף יכול לקבל גישה לחשבונות של משתמשים אחרים ובכך להיות חשוף לפרטיהם, לראות מידע רגיש או לבצע פעולות שהוא לא מורשה לבצע אותן. במערכות בנקאיות באינטרנט נהוג להשתמש במספר החשבון כמפתח הראשי, ולכן זה מפתה להשתמש במספר החשבון באופן ישיר גם בממשק ה-. web באופן זה, גם אם המפתחים השתמשו בשאילתות SQL בטוחות על מנת למנוע,SQL injection תוקף יכול לבצע מניפולציה על מספר החשבון ובכך לראות ולשנות את כל החשבונות במערכת, וזאת במידה ואין מערכת נוספת אשר מוודאת שהמשתמש הוא אכן בעל החשבון ושהוא רשאי לראות את תוכן החשבון ולשנות אותו דוגמאות 1. דוגמה לחשיפה של reference לבסיס הנתונים: בעת גישה לURL מהצורה מתבצע: int cartid = Integer.parseInt( httprequest.getparameter( "cartid" ) ); String query = "SELECT * FROM table WHERE cartid=" + cartid; מוציאים מבקשת ה- HTTP את הפרמטר המסמל את הזיהוי של העגלת הקניות ובונים שאילתת SQL המכילה פרמטר זה. תוקף יכול לשלוח כפרמטר במקום את ה cartid שלו, cartid אחר אשר הוא ניחש )לדוגמה cartid עוקב( ובכך לקבל פרטים של משתמש אחר. 2. דוגמה לחשיפה של reference לקבצים בשרת: נניח שהשרת מקבל מהמשתמש שם קובץ ומציג את תוכן הקובץ. File file = new File (httprequest.getparameter( "filename" )); מוציאים מבקשת ה- HTTP את הפרמטר המסמל את הנתיב של הקוסץ ביחד לתיקיית העבודה של האפליקציה ויוצרים אובייקט של הקובץ הזה. תוקף יכול לשלוח כפרמטר שם קובץ כדוגמת,"../../../../etc/passwd%00" לצאת מהתיקייה של האפליקציה ולגשת למשאבים אחרים הנמצאים על שרת ה.web 13

14 דרכי התגוננות הדרך הטובה ביותר להימנע מהתקפות אלה היא לא לחשוף object reference באופן ישיר למשתמשים וזאת ע"י שימוש בגישה עקיפה, לדוגמה במקום לחשוף שמות קבצים ניתן להשתמש באינדקסים, כך קובץ מספר 1 ממופה ל" myfile.txt ", וכאשר המשתמש רוצה לגשת לקובץ הוא לא שולח את שם הקובץ, אלא את האינדקס שלו. כמו כן, בעת גישה ל- object reference יש לבצע אימות של המשתמש שמנסה לבצע את הגישה. דרך התגוננות נוספת היא לוודא שבכל גישה ל object reference שמאפשרים גישה רק לדברים מוגדרים מראש התקפות מפורסמות בשנת 2000 ארעה התקפה על אתר GST Start Up Assistance של מס ההכנסה האוסטרלי אשר ניצלה object reference חשוף. סטודנט למדעי המחשב, שהיה משתמש חוקי באתר, שם לב לליקוי האבטחה באתר, שינה את המזהה של החברה אשר מהווה חלק מה URL ובכך קיבל גישה למידע של חברות אחרות שהיו במערכת. המשתמש ניגש לפרטיהן של 17,000 חברות, הכוללים בין היתר מספרים של חשבונות בנק. ה"תוקף" שלח לכל אחת מהחברות שפרטיהן נחשפו מייל שאומר להן שפרטיהן אינם בטוחים., דבר שגרם למבוכה רבה לממשלה. Cross Site Request Forgery (CSRF) סקירה כללית התקפת CSRF גורמת לדפדפן של משתמש מחובר לשלוח בקשת HTTP לאפליקציית web פגיעה, אשר מבצעת את הבקשה בשמו של המשתמש המבקש ובהרשאותיו, שכן הוא מזוהה באפליקציה. אם כן, הקוד הזדוני אינו נמצע בד"כ באתר המותקף, על כן התקפה זו נקראת."Cross Site" התקפת CSRF אינה התקפה חדשה, אך היא התקפה פשוטה שיכולה להיות הרת אסון ולכן היא מאוד נפוצה. אפליקציות שפגיעות במיוחד להתקפה זו הן אפליקציות שאינן מבצעות בדיקת הרשאות עבור פעולות רגישות, אפליקציות שמאפשרות לבצע פעולות עם שם משתמש וסיסמא defult -ים כחלק מבקשת ה- HTTP ואפליקציות שמאשרות בקשות HTTP על סמך credentials אשר נשלחים באופן אוטומטי בלבד. דוגמאות ל credentials שנשלחים באופן אוטומטי הן session cookie עבור המשתמשים שמחוברים כרגע לאפליקציה, פונקציונאליות me remember עבור המשתמשים שאינם מחוברים כרגע לאפליקציה, basic authentication כחלק מהתחברות לרשת פנימית, Kerberos של פרוטוקול token Windows domain או SSL של שולח הבקשה, סרטיפיקטים של IP כתובת ה-,credentials.credentials כיום רוב אפליקציות ה- web מסתמכות על credentials אלה ולכן הן פגיעות להתקפות.CSRF 14

15 תיאור בהתקפת CSRF התוקף גורם בד"כ באמצעים של social engineering למשתמש המותקף לטעון דף המכיל בקשת HTTP זדונית אשר יורשת את הזהות וההרשאות של המשתמש המותקף ומבצע פעולות לא רצויות בשמו. דוגמות לפעולות לא רצויות יכולות להיות שינוי פרטיו האישיים של המשתמש, שינוי הסיסמא שלו, ביצוע,logout קנייה של מוצר בשמו ועוד. לרוב התקפות CSRF שמות להן למטרה פונקציות אשר גורמות לשינוי של מצב בשרת ה- web ואשר ניתן להשתמש בהן גם בכדי לגשת למידע רגיש. עבור רוב האתרים, הדפדפנים יצרפו לבקשת ה- HTTP באופן אוטומטי את ה- credentials המקושרים לאותו אתר, כגון session cookie של המשתמש, authentication basic,credentials כתובת ה- IP של שולח הבקשה, Windows domain credentials ועוד, לכן אם המשתמש מזוהה ומאומת מול אתר כלשהו, לאתר אין שום יכולת להבחין בין בקשת משתמש לגיטימית לבין התקפת.CSRF לא חייבים שהאפליקציה תהיה חשופה להתקפות XSS על מנת לבצע בהצלחה התקפת,CSRF אך כל אפליקציה שחשופה להתקפות XSS חשופה גם להתקפות,CSRF שכן התקפות CSRF מנצלות חולשות להתקפות XSS על מנת לגנוב כל credential אשר לא נשלח בצורה אוטומטית ושתפקידו להגן מפני התקפות.CSRF הרבה מהתולעים משלבות את 2 הטכניקות של שימוש בחולשות להתקפות XSS על מנת לפגוע בהגנה של האפליקציה מפני הגנות.CSRF Site התקפת CSRF מכונה גם בשמות נוספים כמו:,One-Click Attacks,Session Riding.XSRF,Hostile Linking, and Automation Attack,Reference Forgery התקפת Stored CSRF לעיתים אפשר לאחסן התקפת CSRF באתר הפגיע עצמו ע"י שמירת תג HTML של img או iframe בשדה המאפשר לקבל,HTML או ע"י התקפת XSS מסובכת יותר. אם התוקף מצליח לאחסן התקפת CSRF באתר עצמו חומרת ההתקפה גדלה פי כמה וכמה, שכן כעת יש סבירות גבוהה יותר שמשתמש מותקף יראה את דף הHTML המכיל את התקפת ה CSRF ויש סבירות גבוהה יותר שהמשתמש המותקף יהיה מזוהה ומאומת באתר וההתקפה תוכל להתבצע השלכות התקפת CSRF מוצלחת יכולה לגרום לחשיפה של מידע של המשתמש המותקף ופעולותיו, ביצוע פעולות כגון קניית מוצרים בשמו במקרה וזהו משתמש רגיל וסיכון ופגיעה באפליקציית ה- web כולה במקרה והמשתמש המותקף הוא מנהל של האפליקציה )administrator( אשר יכול לבצע פעולות רבות. 15

16 דוגמאות דוגמה לאתר המאפשר לבצע פעולות עם שם משתמש וסיסמא defult -ים כחלק מבקשת ה :HTTP httpsss:// wd=admin 2. דוגמה לביצוע פעולות לא רצויות ללא ידיעת המשתמש המותקף: אם התוקף שולח למשתמש המותקף לינק לדף HTML זדוני המכיל את התג הבא בעת ניסיון טעינת התמונה באתר הזדוני זה יגרום למשתמש המותקף לשלוח בקשה שמבצעת logout ללא ידיעתו מאתר אחר לגמרי. <img src=" אם אתר של בנק מאפשר לאפליקציה שלו לעבד בקשות כדוגמת העברת כספים מחשבון לחשבון ניתן לבצע התקפה דומה שתגרום להעברת כספים מחשבון המותקף לחשבון התוקף: <img src=" cct&toacct= &toswiftid=434343&amount= "> דרכי התגוננות הדרך הטובה ביותר להתגונן מפני התקפות CSRF היא לוודא שהאפליקציה אינה מסתמכת על credentials או tokens שנשלחו בצורה אוטומטית ע"י הדפדפן של המשתמש ובעזרת סתימת כל חורי האבטחה שחושפים את האפליקציה להתקפות.XSS חיסול ליקויים המאפשרים התקפות -XSS כאשר בונים הגנה מפני התקפות,CSRF יש תחילה להתמקד ולוודא שלא קיימים ליקויים המאפשרים התקפות XSS באפליקציה כיוון שניתן לנצל חולשות אלה על מנת לעקוף הגנות מפני התקפות CSRF אשר קיימות באפליקציה. שימוש ב credentials שאינן נשלחים בצורה אוטומטית ע"י הדפדפן- יש להשתמש ב- token אקראי שנוצר במיוחד כך שהדפדפן לא יזכור אותו ולא ישלח אותו כחלק מהמידע שנשלח בצורה אוטומטית, בנוסף יש לוודא שה- token שהתקבל אכן נכון עבור המשתמש. יש להשתמש ב- tokens שיהיו ייחודיים לפונקציה או דף מסוים עבור משתמש מסוים או ייחודיים עבור ה- session כולו. ככל שה token יותר קשור לפונקציה מסוימת או מידע מסוים כך מצד אחד ההגנה תהיה חזקה יותר ומצד שני המימוש והתחזוקה של המנגנון יהיו קשים יותר

17 ביצוע אימות נוסף בעת העברת מידע רגיש - עבור העברת מידע רגיש יש לבצע אימות נוסף או להשתמש בחתימות על מנת לוודא שהבקשה אכן לגיטימית. יש להשתמש במנגנון וידוא חיצוני כגון אימייל או טלפון על מנת לאמת את הבקשות או להודיע למשתמש על ביצוע הבקשה. אין להשתמש בבקשות HTTP מסוג GET בכדי להעביר מידע רגיש, אלא רק בבקשות מסוג.POST עם זאת, שימוש ב POST לבדו אינו מספק הגנה מספקת לכן חייבים לשלב עם POST שימוש ב tokens אקראיים, אימות out of band או אימות נוסף על מנת להגן בצורה מספקת מפני התקפות.CSRF התקפות מפורסמות באפריל 2009 מייקי מוני, יוצר הרשת החברתית StalkDaily המתחרה ב טוויטר, הודה כי פרץ לטוויטר ע"י כתיבה של תולעת שמפיצה את עצמה וגורמת לכל המשתמשים הנגועים לפרסם הודעות לגבי.StalkDaily תולעת זו מנצלת חולשות XSS ו CSRF הקיימות בטוויטר. טוויטר פגיע להתקפות XSS בכך שמשתמש יכול להעלות תוכן זדוני בפרופיל שלו וכל משתמש שמסתכל בפרופיל נפגע גם הוא. מעבר לכך, טוויטר פגיע להתקפות,CSRF כלומר, ניתן להריץ את הקוד הזדוני תחת הרשאות המשתמש המותקף ובכך לתקוף את החברים שלו ואת החברים שלהם וכן הלאה וכך בדיוק התולעת פעלה. ב 2006 ג'רמיה גרוסמן הדגים שניתן לאלץ משתמש לבצע שינויים בנתב ה DSL שלו ללא הסכמתו גם כאשר המשתמש כלל לא מודע לעובדה שלנתב שלו יש ממשק.web גרוסמן השתמש בחשבון ה- default -י של הנתב על מנת לבצע את ההתקפה. כל ההתקפות האלו עבדו בגלל שה- credential של המשתמש )בד"כ )session cookie מצורף בצורה אוטומטית ע"י הדפדפן לבקשות מהסוג הזה גם כאשר התוקף לא מספק את ה-. credential Information Leakage and Improper Error Handling סקירה כללית אפליקציות web יכולות לגלות למשתמש מידע מיותר שעלול לשמש להתקפה. האפליקציות יכולות לגלות מידע על הקונפיגורציה שלהן, צורת הפעולה הפנימית שלהן ועוד. ניתן ללמוד על המצבים הפנימיים של אפליקציה בהתאם לזמן שלוקח לה לעבד פעולות מסוימות או לפי תגובות שונות לקלטים שונים, לדוגמה, אם האפליקציה מציגה אותה שגיאת טקסט, אך עם מספרי שגיאות שונים. לעיתים קרובות אפליקציות web יגלו מידע מיותר דרך הודעות שגיאה או הודעות debugging אשר אינן מטופלות בצורה טובה, שכן באפליקציות אלה כל הזמן קורות שגיאות: נגמר הזיכרון, יותר מידי משתמשים מחוברים,,timeout כישלון בעת שאילתה של בסיס הנתונים, כישלון בעת הזדהות של משתמש, כישלון בעת בקרת גישה של משתמש, קלט לא חוקי ועוד... 17

18 אם תוקף יכול לגרום לשגיאות שאפליקציית ה- web אינה מטפלת בהן כראוי, הוא יכול לקבל מידע מפורט על המערכת,לפגוע במנגנון האבטחה, לגרום לנפילת השרת או לנפילת service שהשרת נותן ובכך לגרום ל- service deny of למשתמשים אחרים. בנוסף לכל אלה תוקף יכול לנצל את המידע שקיבל על מנת לבצע התקפה יותר משוכללת ויותר חזקה ואף על מנת לבצע התקפה אוטומטית דוגמאות 1. להודעת שגיאה שמציגה מידע debugging מפורט מידי: הודעת שגיאה המציגה stack traces או שאילתות SQL שלא בוצעו בהצלחה. 2. דוגמה לפעולה שמספקת תוצאות שונות עבור קלטים שונים: מערכת שמכניסים בה שם משתמש וסיסמא ומפיקה הודעות שגיאה שונות אשר מאפשרות להבדיל בין מקרה בו שם המשתמש שהוכנס שגוי לבין מקרה בו הסיסמא שהוכנסה שגויה. דוגמה להודעת שגיאה שמתקבלת באתר הרישום של הטכניון ) כאשר המערכת תחת עומס:.3 Warning: ocilogon(): _oci_open_server: ORA-12500: TNS:listener failed to start a dedicated server process in /var/u/ugweb/share/htdocs/rishum/database.php on line 19 Database Error (connect) הודעה זו חושפת שמות קבצים, סוג בסיס הנתונים, שמות פונקציות ומספרי שורות דרכי התגוננות האפליקציה כולה צריכה להיות בעלת ארכיטקטורה התומכת בטיפול סטנדרטי בשגיאות אשר יהיה מתוכנ היטב, קונסיסטנטי וימנע גילוי של מידע לא רצוי לתוקפים. בעת התרחשות של שגיאה יש לתת למשתמש מידע שיאפשר לו לדעת מה הבעיה, אך יש לוודא שהודעת השגיאה אינה מציגה מידע מפורט מידי, כמו כן, יש לתעד את השגיאה שקרתה בצורה מפורטת ואין לחשוף תיעוד זה למשתמש. בנוסף לאלה יש לבצע,logout למחוק מידע רגיש, לשלוח מייל וכו' התקפות מפורסמות בספטמבר 2000 משתמש גילה פירצת אבטחה באתר של חברת הרהיטים איקאה בעת שניסה להזמין קטלוג דרך אתר האינטרנט. כאשר המשתמש ניסה להזין את פרטיו הוא נתקל בהודעת שגיאה אשר נתנה את שם קובץ בסיס הנתונים, כעת הוא יכל להזין את שם הקובץ בשורת הכתובת בדפדפן ולגשת לכל בסיס הנתונים, שכלל שמות, כתובות, מספרי טלפון ואי מיילים של לקוחות שהזמינו קטלוגים של איקאה. 18

19 Broken Authentication and Session Management סקירה כללית כפי שנלמד בקורס הגנה במערכות מתוכנתות, יש להגן על מידע רגיש בעזרת קריפטוגרפיה ועל תקשורת בה מועבר מידע רגיש באמצעות פרוטוקולים מתאימים, זה נכון גם באפליקציות.web אימות מספק וניהול נכון של session הם קריטיים לאבטחת האפליקציה וליקויים בתחום זה כוללים לרוב אי יכולת להגן בצורה מספקת על credentials ומזהים של sessions בזמן מחזור החיים שלהם. ליקויים אלה יכולים להוביל לגילוי סיסמאות, מפתחות הצפנה, session cookies ומזהים אחרים אשר מאפשרים חטיפת חשבונות של משתמשים ומנהלי מערכת בכדי להתגבר על מנגנון האימות. ליקויים במנגנוני האימות הראשיים אינם נפוצים במיוחד, עם זאת, ליקויים באימות ובניהול ה session בד"כ חודרים למערכת דרך מנגנוני האימות המשניים, לדוגמה: מנגנון,logout מנגנון ניהול סיסמאות,,timeout, remember me שאלה סודית, עדכון פרטי חשבון דרכי התגוננות אימות מסתמך על תקשורת ושמירת credentials מאובטחים, לכן יש לדאוג שכל תקשורת מאובטחת בכל חלק של האפליקציה מבוצעת באמצעות,SSL כמו כן, יש לדאוג שה- credentials נשמרים בצורה מוצפנת או מתומצת. דרך נוספת להתגונן היא להשתמש רק ב- session id אקראי שהמערכת מספקת. Insecure Cryptographic Storage סקירה כללית כפי שנלמד בקורס הגנה במערכות מתוכנתות, יש להגן על מידע רגיש בעזרת קריפטוגרפיה, עם זאת, אפליקציות web רבות בעלות ליקויים בתחום זה. אפליקציות רבות אינן מצפינות מידע רגיש או בעלות design לקוי של הקריפטוגרפיה, לדוגמה משתמשות בצפנים לא מתאימים, או משתמשות בצורה לא נכונה בצפנים מאוד חזקים. ליקויים אלה יכולים להוביל לחשיפה של מידע רגיש דרכי התגוננות תחילה יש לוודא שכל מידע שצריך להיות מוצפן אכן מוצפן, ולאחר מכן יש לוודא שהקריפטוגרפיה ממומשת בצורה נכונה. 19

20 Insecure Communications סקירה כללית כפי שנלמד בקורס הגנה במערכות מתוכנתות, יש להגן על תקשורת בה מועבר מידע רגיש באמצעות פרוטוקולים מתאימים, אך אפליקציות web רבות לא מגנות על התקשורת בצורה מספקת. יש להשתמש בהצפנה )בד"כ ב )SSL עבור כל ה connections המאומתים, בין אם הם עם מחשב ברשת חיצונית כגון האינטרנט, או עם מחשב ברשת הפנימית דרכי התגוננות יש להשתמש ב SSL עבור כל connection מאומת וכאשר מועבר מידע רגיש. על מנת לקנפג בצורה נכונה את ה- SSL יש להיות בקיא בסביבה של האפליקציה. Failure to Restrict URL Access סקירה כללית לעיתים קרובות ההגנה היחידה שיש לדף אינטרנט היא שהלינק אליו לא מוצג למשתמש שאינו מורשה לגשת אליו. יחד עם זאת, תוקף מוכשר, או סתם בר מזל, יכול למצוא דפים אלה, לגשת אליהם, להפעיל פונקציות, לראות מידע ועוד. אם כן, גישת security by,obscurity לפיה מסתמכים על אי חשיפת הלינק בתצוגה, אינה מספיקה להבטיח שהמידע והפונקציות הרגישים של האפליקציה יהיו מוגנים. יש לבצע בדיקות אימות לפני קריאת לפונקציה רגישה או מידע רגיש על מנת לוודא שלמשתמש אכן יש הרשאות מתאימות המאפשרות לו גישה לנתונים אלה דוגמאות.1 URL -ים )דפי אינטרנט( שהלינק אליהם נראה בתצוגה רק למנהלי רשת או למשתמשים בעלי הרשאות, אך כל המשתמשים יכולים לגשת אליהם במידה והם יודעים את הכתובת, לדוגמה: /admin/adduser.php או./approveTransfer.do בעיה זו נפוצה בעיקר בתצוגות של תפריט פעולות. קוד שמאמת את המשתמש בצד של הלקוח, אך לא מאמת את המשתמש בצד של השרת..2 20

21 דרכי התגוננות על מנת להגן מפני מגישה לא מוגבלת ל- URL -ים יש לתכן בקפידה את ההרשאות ע"י יצירת מטריצה הממפה את התפקידים והפונקציות של האפליקציה. אפליקציות web חייבות לאכוף בקרת כניסה בכל גישה ל- URL ופונקציה, שכן זה לא מספיק להשאיר את בקרת הגישה לשכבת התצוגה בלבד. כמו כן, יש לאמת בכל צעד וצעד את המשתמש ולבדוק האם הוא מורשה לבצע את הפעולה, אחרת, תוקף יכול לדלג על שלב ביצוע האימות ולזייף את ערכי הפרמטרים הנחוצים על מנת להמשיך לשלב הבא התקפות מפורסמות בספטמבר 2000 אתר חברת העברת הכספים Western Union נפרץ. בעת ביצוע תחזוקה שגרתית של האתר הושארו לקבצים מסוימים הרשאות גישה המאפשרות גישה לכולם וכך התאפשר לתוקף להעתיק מידע לגבי כרטיסי אשראי וחובות של 15,700 לקוחות. Unvalidated Parameters.11.3 נציין בקצרה גם התקפה זו שהייתה בשנת 2004 לפי OWASP ההתקפה הכי מסוכנות על אפליקציות web והיא באה לידי ביטוי כחלק משאר ההתקפות שצוינו סקירה כללית בקשות HTTP שנשלחות מדפדפנים לאפליקציות web מכילות,URL מחרוזות שהוכנסו לתוך שדות, שדות נסתרים, cookies ו-.headers אפליקציות ה- web משתמשות במידע זה על מנת לייצר את דף האינטרנט המתאים ולשלוח אותו כתגובה לבקשה. תוקפים יכולים לשנות כל אלמנט בבקשת ה- HTTP ובכך לתקוף את האפליקציה, במיוחד אם האפליקציה לא מוודאת את תקינות הנתונים שהיא מקבלת או מסתמכת על בדיקות שמתבצעות בצד של המשתמש דרכי התגוננות על מנת להבטיח שאף גורם לא שינה את הפרמטרים יש להפוך את הפרמטרים לייצוג הקנוני שלהם ובדוק אותם לפני שמתבצע כל שימוש בהם. יש לבדוק כל פרמטר מול פורמט מוגדר מראש שמגדיר במדויק את הערכים החוקיים, כלומר יש להשתמש בשיטת whitelist ולא לסנן קלטים לפי שיטת blacklist או לנסות לתקן אותם. כמו כן, תמיד יש צורך לבצע וולידציה בצד של השרת ואין להסתמך על וולידציה המתבצעת בצד של הלקוח, גם אם ידוע שהלקוח מבצע וולידציה ובדיקה של הפרמטרים בבקשת ה-.HTTP 21

22 סיכום מספר התקפות על אתרי web רק הולך וגובר, כמו כן, סוגי ההתקפות הנפוצים הולכים ומשתנים, מהתקפות שמטרתן שיבוש של האתר והקניית מוניטין לתוקף עברו התוקפים להתקפות שמטרתן גניבת מידע למטרות רווח..4 ארגונים רבים לא עוקבים אחר פעולות המתבצעות ברמת אפליקציית ה-,web על כן כל תוקף מנוסה המצויד בדפדפן אינטרנט וקצת נחישות יכול לנצל גם את חורי האבטחה הקטנים ביותר באתר על מנת לפרוץ אותו. יתר על כן, נראה כאילו רוב ההתקפות מתגלות חודשים אחרי שבוצעו בפועל, אם בכלל, שכן באפליקציות web לעיתים אין "ראיות פיזיות" לכך שהתבצע התקפה )לדוגמה שיבוש בבסיס הנתונים(, וזאת כיוון שתוקפים בד"כ רוצים לגנוב את המידע, ולא לשבש אותו. מחקרים משנת מראים כי כ 75% מההתקפות הממוחשבות מבוצעות ברמת אפליקציות ה-,web וכפי שנאמר קודם, התקפות אלה גורמות להפסדים רבים. להלן גרף המסכם את ההפסדים לשנת 2007 בארה"ב לפי CSI/FBI Annual Computer Crime,and Security Survey כאשר גרף זה אינו מתאר הפסדים עקיפים של ההתקפות, הנובעים בעקבות ירידת מוניטין החברה ואיבוד לקוחות פוטנציאליים: 22

23 הדיאגראמה נלקחה מתוך דו"ח CSI/FBI Annual Computer Crime and Security Survey המקורות(. לשנת 2007 )מס' 15 ברשימת 23

24 מקורות רשימת ה- Top 10 של OWASP לשנת כמו כן, השתמשנו בלינקים לכל אחת מההתקפות המופיעות בלינק זה מצגת המתארת את רשימת ה- Top 10 של OWASP לשנת רשימת התקפות קיימות לפי OWASP.השתמשנו בלינקים לכל אחת מההתקפות שב- Top 10 של OWASP המופיעות בלינק זה allyfindowasptop10.ppt מצגת של OWASP המתארת את הבדיקות שצריך לעשות על מנת להימנע מההתקפות שברשימת ה- Top 10 של OWASP לשנת מתאר באופן כללי את ההתקפות והסכנות שיש ברשת והשפעתן מתאר את סטטיסטיקות לגבי התקפות נפוצות ואת המחיר של הנזק לו הן גורמות df מצגת המתארת את רשימת ה- Top 10 של WhiteHat Security לשנת 2009 ורשימת סטטיסטיקות לגבי ההתקפות השונות מתאר התקפה מסוג Cross Site Scripting שבוצעה על אתר.MySpace 9. מתאר בצורה מפורטת התקפה מסוג Cross Site Scripting שבוצעה על אתר.MySpace מתאר התקפה מסוג Insecure Direct Object Reference שבוצעה על אתר GST Start.Up Assistance רשימת התקפות רשת מפורסמות וסיווגן לסוגים. באתר זה מצאנו את רוב הדוגמאות להתקפות שפירטנו עליהן מתאר התקפה מסוג Injection Flaws שבוצעה על אתר.CardSystems _File.pdf מתאר התקפות מסוג Remote File Inclusion ודרכי ההתגוננות מפניהן מתאר התקפה מסוג Information Leakage and Improper Error Handling שבוצעה על אתר איקאה. 24

25 15. דו"ח CSI/FBI Annual Computer Crime and Security Survey לשנת מצגת המתארת את התקפות ה- XSS השונות, איך לזהות אותן ואיך למנוע אותן. 25